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Ajpli^taveas^toExanun^amento^totheapp^tusd^stohKludea 

p, cesser to clarify and more distinctly point out and daim applicant invention but 
no t to overcome any prior art The amendment, made incorporate terms of description 

an 1 not of limi tabon 

A 3 Scants respectfully submit that the distinction between applicants' invention and 

re llining was addressed in applicants' parent applications. In the excerpts below, 

ai : plicants have indicated inbold face type in brackets where the cited portions of the 

p irent specification are found in the current pending application {bold face in brackets 

fo , current pending application 1. In the parent cases it was noted that: 

For the phrase "automated negotiations engine" ^PPo^ is Wd i to ithe 
specification at Page 60, lines 9-20 Page 61 hnes 1-1.8, and Pag 18 ' 
[Page 66, lines and Page 67, lines 1-18 and Page 68, line « ™ e « ™ e „ 
professing steps of the automated negotiations engine are described. On Page 62, 
lines 11-16 [Page 68, lines 9-14], for example, state: 

nnes ir a whemer or not a concluding document is requested, the system 
automatically displays the changes so they can be easily seen and the 
p^sentmve ntionalso checks to see whether a state change is needed at 
Step 212-16. If a state change is needed it is initiated at step 212-ZU. 
Depending on the community, the participants, and the transactions 
Kved ftete changes could be as simp^ as payment ^thon^tions sent 
electroracaUy or as complex as multi-step processes desired by the 
participants. [Emphasis added! 

Also, as noted in the specification at page 52, lines 14-18 and Page 53, Hnes 1-4 
[Page 58, lines 3-12]: 

Next, in Figure 1L, network functions 207 of the present invention 
are shown. As mentioned above, most of the functions of "ff*™** 
■^ r M 3 Hnn. P n ff inp 212 are y +n«11v implemented as part of Webserver 
^ware210s. As data is sent to and from the Internet 04 by Webserver 
rffflAT wa^rver software 210s intern "^ the TCP-IP protocol and 
tra pcforc the mnt«nts to multivariate negotiations en gme 212, s 
Webserver and dynamic HTML functions 207-02Tfr^ne embodiment, 
tW fiir^—° ^ y™mir HTML text lobe created to implement and 
.nrnxnunicate wi t h ^ functions of the present invenfaon Those 
skilled in the art will appreciate that Java, Java scripting , XML, or any ot 
a number of other languages could also be used for such communications. 
[Emphasis added] 
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example referenced above. 

and Page 94, to«J^= and ^ m R 5a> a a buyer participant 08 wishes 
to Dbcfa pr 0 3 order, the browser encrypts it at the browser's secure 
2S2S5SSd^rf«r^ 210s decrypts the proposed otden upon receipt 
S S negotiations engine 02's site. W ebserver 210s .next analyz es 
g^ pnspH ordlr to unrlrr-hffl d it <md formats into a reque st s ent to 
S^gl^o^22Tfa addition to basic read and write ™cbons 
A **h»se ftmctior ^ " " pure 5a. include <>P^ ab f^ f^y 

Formatting can be as simple as "user = usemame etc A request such as 
"fiSSusername, return catalog" might be sent through IP firewall 
203f . [Emphasis added] 

■ User supplied context, which can be defined as a number oS ^ er f^^ le 
terms oFitems as noted in the specification at page 44, lines 19 and 20 [Page 49, 
lines 18-19 and Page 50, line 1], for example, include * » 
sponsor, terms and conditions supplied by a seller, terms supplied by a buyer, 
etc., as shown in more detail below. 



An example of "user supplied context" is found in the specification at Page 65, 

Unes 7 -12 [Page 71, lines 8-13], where the user is a buyer: 

Now referring to Figure 15b, a typical proposal form for a buyer is 
shown. As seen here, the buyer identifies himself, his title his company, 
and*e company's location at lines 332-342. At lines 344-350 mtoatton 
ahnnt the buyer's H eated freight forwarder is given. At hne 350, 
^.mpnt presentatio n terms are sppcified. as well as at line 352, 354 358 
a nH sn cm. the detail^ terms of the hiivPr's preferences for shipment. 
[Emphasis added] 

Another example of "User supplied context" is found in the specification at 
page 45, lines 6-9 [Page 50, lines 7-10], where the user is a sponsor: 

The sponsoring standards body establishes the community, 
proposes ^w.i ^nH^rds. sets the rules for negot iations, encourages and 
monitors negotiations, and concludes with a finally agreed upon set of 
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creates on. or more redline documents 218." Col. 7, . ^ «*£J5g?/fSs 
two text versions of a document for comparison and, as disclosed at Col. 11, lines 

46-58: 

If at the decision block 702, the user selects a redline function, the 
system controller 102 branches to a process block ^^tTSh^ 
718 the system controller 102 activates the redhne unit 120. The redbne 
unit 120 prompts the user to select to {sicj 01es to be compared. A redlme 
comparison is typically done between a current document and either a 
corresponding standard document or a previous revision of the same 
document. The redline unit 120 generates a new file that specifies the 
differences between the two files selected by the user, without affecting 
the selected files. The redline unit 120 may be implemented, for example 
[sic] a redlining program such as CompareRite. [Emphasis added] 

Redlining, as described above, is a text comparison of two documents. Changes 
in the text are underlined, usually in red, or "redlined." The program that does 
the redlining does not analyze the changes in any way, or prompt actions as a 
result of them. 

Applicants' invention, by contrast, during the negotiations process, provides an 
au tomated negotiations engine that analyzes terms by understanding their 
purpose, formats them according to their purpose, and places them in a user 
supplied context for use by a user. The automated negotiations engine also 
recognizes changes in the terms and indicates what has changed. It can also 
prompt for additional information as a result of a change. For example, if a 
shipping term such as Ex Works, has changed to Deliver Duty Free, the 
automated negotiations engine system of applicants' invention knows what 
additional information to request from the user, such as the name of the user's 
freight forwarder, and will format requests for that information. 

Support for this is found in applicants specification at Page 86, lines 15-19 and 
Page 87, lines 1-4 {Page 93, lines 16-18 and Page 94, lines 1-6], as referenced 
above, as well as in Figure 15 C-l and Figure 15 C-2. 



A :>plicants respectfully submit that the above clarifications apply to the present 
a| plication as well. Unlike redlining, applicants' invention analyzes terms, the analysis 
of terms comprising understanding their purpose, formatting the terms according to the 
pi irpose and placing them into user supplied context for use by a user. As shown above, 
us er supplied context refers to the fact that users of applicants' invention can supply the 
cc ntext for one or more negotiations. In ttie illustrative examples shown in the 
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standards, with each step of each negotiation that occurred along the way 
archived. (Emphasis added] 

Still another example of "User supplied contexr is seen in th e _^ ca ^ r 
Page 49, lines 6-15 [Page 54, lines 11-17 and Page 55, lines 1-3], where the user is 
a seller: 

Now turning to Figure lg, the present invention can be viewed as a 
series of interrelated processes as shown here. For a commercial 
community, there are seller processes, sponsor processes and buyer 
processes. Remote authoring 50, is a seller process which ^enables > a 
registered seller in the community to create a seller Website withm the 
community on which to include foe. s . eUer's marketing and product 
^Wm*Hnn alnn ? with pp Hnp. terms, service offerings and so on,, 
TpWmaHon generated or created i n this remote authotwff process 5U is 
ai.tomaricallv in te grated with t he immunity databases and hstmgs. 
Promotion and brand identifying actions (such as registering the .Web 
page with search engines) are taken automatically on behalf of the seller 
as well. [Emphasis added] 

Support for the phrases "recognizing any changes in the terms" and "the 

automated negotiations engine indicating any changes 

specification at Page 62, lines 1-3 (Page 67 hnesl7-18 and Page M Uine 1]. 

A/fniti^riate ne gotiations erm ine 212 keeps track of each set of 
changes and can dis play them so that the changes proposed at each step of 
the negotiations are clearly and accurately recorded. (Emphasis added) 

US Patent No. 5,692,206, to Shirley et al (Shirley) was brought to appUcants' 
attention as potentially rendering obvious applicants' invention s negotiations 
eneine and indication of changes as part of a negotiations process. Applicants 
respectfully disagree. Shirley describes a document generation system which 
helps a user create a document for use in a negotiation, but it does not automate 
the negotiations process. (See Col 2, lines 11-45 in vvhich it is clear that Shirley 
describes a system of libraries of standard terms from which a user can manually 
select one or more provisions.) Shirley discloses a "negotiating database which 
is not an automated negotiations engine but simply a file or database for folding 
"one or more corporate suggestions 442 and one or more user notes 444. ^ol 5, 
lines 49-51. In Col. 7, lines 14-40, it is clear that Shirley describes a system m 
which the user selects from a library of standard contract provisions those 
provisions the user wants to incorporate into his or her contract proposal. This is 
not a negotiations process, but simply a way to create a proposed contract 
document that one party might send to another by regular mail, fax, or e-mail. It 
teaches away from applicants' invention by focusing on word -processing-like 
document assembly techniques, not on negotiation processes. 

Finally, Shirley does not teach, disclose or render obvious an automated 
negotiations engine for indicating changes in the proposed terms. Instead, it 
teaches away from this as well, by teaching a redlining feature in which "the user 
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sp rcification and the drawings, user supplied context has included, among other 
ft op: community rules; standards; buyer's terms; seller's terms; sponsor, seller, 
i buyer processes; application programming interfaces; templates; administrative 
ormation; product information; procedures; text, image and sound files; deciding 
lines, and numerous other items, according to the kind of negotiation and the kinds 
of ,asers involved. Non-commercial users may supply very different types of user 
n, pplied context as shown in the parent application at Page 61, lines 2-6 {Page 66, line 
18 and Page 67, lines 1-4]. 

In the discussion with the Examiner, applicants were also asked to clarify the 
di .unctions between applicants' invention and that which is claimed and disclosed in 
U , Patent. No. 6,055,519 issued to Kennedy et al on April 25, 2000, entitled 
"I ramework for Negotiation and Tracking of Sale of Goods ("Kennedy")- 

A .plicants respectfully submit that Kennedy does not disclose, claim, nor render 
ot 'Vious an automated negotiations system for processing negotiations. The Kennedy 
s> stem does not process negotiations, but stores data representing the current state of a 
n. gotiation, to allow the user to monitor the state of a negotiation. This is stated in the 
A :«tract as follows: 

A computer implemented system and process are provided for negotiation and 
tracking of sale of goods. In this system and process, a negotiation engine 11,6) , 
L«Jk to store date presenting a current state (1 8) o f a negotiation between a 
4jw ^rtri H„ y ^ Thp ne gotiation eo fnno (16) stores the data within a framew ork 
for representing aspects of the negotiation between the s eller and buyer. 1 he 
framework includes a request object, a promise object and an acceptance object 
that can store a current descriptio n of a contract. The framework also includes a 
iet "of one or more delivery deals determined by the contract. Each delivery deal 
can have a delivery request object, a delivery promise object, and a delivery 
acceptance object that can store associated item deals and time periods tor 
delivery of item deals. Each item deal can have an item request object, an item 



6 

Received from < 000000000000000000 > at 8(20103 5:38:29 PM [Eastern Daylight Time] 



PAGE 08 

08/21/2093 17: 28 000000000000800000 

A TORNEY DKT NO. ETOO-OOlOF PATENTS 

current state of the negotiation . . . 
Ti is is also clear from the following text in the description of the Kennedy patent at 

O il. 4, lines 4-17: 

Buyer 14 can have a negotiation client 22 that communicates with 
negouahWngine 16 across a network communication layer Negotianon chent 
22 can comprise a software application executed by a computer system and 
g ™ ryiprv rt A state ia Negotiation g can* ! used to 

communicate requests and acceptances trom buyer 14 to seller 12, and 
Sttati^r? engine 16 can be used to communicate promises from seUer 12 to 
S^^u- Lpf, p^n^ and acceptance informanon can also be 

»ih«r meapc ,A bv fax. phone, etc. According to the 

current state 18 to reduce or eliminate any confusion about the status of the 
negotiation and relevant terms. [Emphasis added] 

E S sentially, Kennedy stores data objects of limited types which represent a request, a 
p, omise or an acceptance. Since the data stored in the objects could have been 
cc mmunicated by fax or telephone, it is dear that Kennedy is simply storing the data, 
n« .t processing a negotiation. The Kennedy "negotiation engine" stores these objects, 
at d as will be seen below, uses the time stamps associated with each to determine the 
st iitus of the "negotiation". 

H ds state monitoring is described at Col. 5, lines 50-57 as follows: 

In tn „ ^^O e 0 p^ ;mmnHnn f the state that a negotiation is in canbe 
dete rmined, for example, from the relative values of four time stamps: the date 
that the most recent request was issued, the date that the most recent promise 
was offered, the date that the most recent acceptance was made, and the most 
recent date that the request was queued. If there is only a request issued date, 
then the negotiation can be identified as being in state 32. [Emphasis added]. 

K nnedy also states at Col. 4,lines 26-35: 
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transition: the buyer can issue a new ^'^^^^l " mise 

(V\ the buver can queue a request (Q), the Duyer can accept a y% 
S) ^buy^r ZZlJor withdSw a request (D^AII five <^mt^ 
{ JZ£~*V Jni«,hte to each state. In particular, the buyer can delete or 
iSSEff arrest until it is ac cipted, but once accepted, the request can no 
longer be withdrawn by the buyerJEmphasis added} 

Tl iis makes it dear that the system itself is only reporting on state transitions. It is 
tn eking what the buyer and seller have done in the past, as the description expressly 

st ites at Col 6, lines 19-25: 

...the negotiation process can thus be tracked between buyer and sdte 'in 
constrained environment by providing a framework for 
the state diagram of FIG. 2 while also storing the current state of and relevant 
data for the negotiation [Emphasis added] 

Tl |e limitations on a buyer and seller are illustrated by the following sample, from col. 4, 
lii es 48-54: 

From state 34, the buyer can do one of four things The buyer can delete or 
withdraw the request which moves the negotiation back to state 30. The buyer 
tissue a new request, moving the negotiation to state 36. The buyer can queue 
^SnV^quest, moVing thf negotiation to state 38, and the buyer can accept 
the promise, moving the negotiation to state 40. 

Ft rther, Kennedy does not recognize the users as negotiators or recognize one of them 
as a deciding entity. 



In .tead, Kennedy is simply monitoring and tracking the state of some very limited 
rununications between a buyer and a seller. Even while describing some of its 
antages, this is made apparent at Col. 6, lines 43-50: 

The present invention provides numerous advantages over conventional 
negotiation processes. First, thr react state of the negotiation is detailed in such a 
way that automated and semi-automated decision systems (such as planning 
systems, order fulfillment systems, purchasing systems, supply chain 



cc 
at v; 



8 

Received from < 000000000000000000 > at 8/20/03 5:38:29 PM [Eastern Daylight Time] 



„„„„„ PAGE 10 

08/21/2003 17:28 000000000000000900 

_ PATENTS 
Ai TORNEY DKT NO. ETOO-OOlCE? 

management systems, etc.) can work against th^temjte state transitions, and 
deal with the changes in states over time. [Emphasis added.) 

Tt is, and similar sections of the specification make it readily apparent that this is a 
m. initoring and reporting system, not a negotiations system. 

In add**, the system appears to be primarily designed for the use of planners (not 
m gpfiatan) for order or demand management systems in either a buyer- * « seller's 
or nanization as seen at Col. 9, lines 57-64: 

The Request, Delivery Request, and Item Request structures togetiier 
model and provide a framework for requests from one si e to another TJy 
g^-fygL-T p — » nti Trp ™ Pr o ™" P ^ rtures aether model arv d 

ffl r-n— "" f> These, struct"^ fro ^ether imn^ent what is traditionally 
^ I^ ^l^ ^.nf o r "Dem and Ma nagement ^ Simplified variations of 
Sose structures are often called "orders." [Emphasis added] 

A ; part of this, the Kennedy specification describes some specific formats and types of 
re iuest, promise and acceptance objects, containing predefined fields for data such as 
quantity, due date, price, etc. If a buyer and seller use these predefined object formats 
ai d fields, the system can track their communications and feed the specific data into 
o, i ter management or demand management systems. Alternately, as stated above, their 
cc despondence by telephone or fax can be stored in these formats and thus tracked. 

T3 „e specification states at col. 14, lines 39-41 that "The basic information provided is the 
st ,te of the negotiation for each order (e.g. whether the order is Requested, Promised, or 
A :cepted)." and, at Col. 14, lines 42-52 that: 

Additional information can be provided which is termed "problems". An 
example problem is an order whose Promise does not match the Request 
Another example is an order that is Promised but not Accepted (part of the 
"basic information" mentioned above). Another example is an order that is 
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ggg JJS .h- ianpfr chain. IBmphasB added! 
to Iterance of the above statement the specification describe,, at Col. 14, lines 6W7 

and Col. 15, lines 1-3 : 

types of problems that can be identified. It covers the meting of each 
probleiKata^sed to identify the problem, and where 

Mmimt* or red* ™ «*» ^verity n* the problem, {Emphasis added! 

A i example of one of the types of problems which the invention can identify is found at 

Gil. 15, lines 10-21: 

A "Reauest Not Planned" problem indicates that the item request was 
issnedafterXTtem promise ^<^^^*^ 1™ ^igb** 
pkmned to satisfy the item request either there is no ^dehvery plan , or the 
SSEyptan* 5for the olderitem promise. This Problem will not occur tf the 
delivery request has an infinite Mue* Date, the item request is for a «~ 
? quan5ty\ or the item promise was offered after the item request was *»ued (or 
last modified). To ™nb ™ this Pr"^™ either eliminate or zero out the tern 
ZL £ff Hlik riv). -offer ' » and switch mejdel ivgrv^ bn to satisfy the 

^T JT^Ji ~T*" the ^delivery plan to meet the^ 

requeSt .fEmphasis added] 

A i this example, and the others show, this problem identification is done, for the most 
?i rt, after the fact, when the negotiation has presumably completed and primarily for 
ft e benefit of the planner or demand management system, not the negotiators. 



If irhe planner uses one of the recommended solutions to "fix" the problem, the system 
w ill update the problem data, and reflect that, as described in the specification as well, 

al Col. 18, lines 1-13: 

As any change occurs to the data of a Request, Promise, Acceptance, 
Delivery Request, Delivery Promise, Delivery Acceptance, Item Request, Item 
Promise, or Item Acceptance, the invention reanalyzes the date and updates the 
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identified problems. Data changes cause some problems to ^ BB ^^. 
titentiaUv others to be rrrV-* T±- h "™ an r lanner can Bee .,? eBe m a 

SSSSset interface «r ff^^^ 

"« _ M ^ Q frkoco wuh* bv notification of which problems are 

ST*-" p**l«™ »nd an inte**™ t" an automated planner ^whi£h 

the s»™*™ nf seated and destroyed p roblem s. [Emphasis added) 



K« nnedy does state, at Col 18, lines 14-28 that in connection with such problems, : 

Changes can be made at any point in a negotiation including after the 
negotiation is traditionally viewed as ' complete" (Acceptance is made). 
After acceptance, the seller and buyer both have the ability to reopen 
negotiations. The seller is allowed to change the Promise to reopen 
negotiations. The buyer is allowed to change the Request to reopen 
negotiations. (The invention allows this, although some applications of the 
invention may not. In a manufacturing operation, machine breakages and 
strikes really require that promises be broken. Likewise, a supplier can 
rarely be rigid with their customers" requests.) When such changes occur. 
r PQuest-promisg-arraptance p™M»ffl calculations can be rerun. However, a 
locking mechanism can be used to prevent request and promise datafrom 
changing and instead reporting a warning if any entity attempts to change 
such data. [Emphasis added.] 

It ,s clear both from the specification and the claims, that this identification of problem 
cc nditions is used to, as Kennedy's Claim 14 puts it "pinpoint mistakes in the 



nt jjotiation." 



K nnedy does not disclose or claim or render obvious a system for processing 

nt jjotiations, but a system for monitoring state transitions amongst a set of narrowly 

d« lined objects. 

K- nnedy does not recognize the users as negotiators nor does it recognize one of them 
as a deciding entity. It appears that one primary user of the system described in 
K nnedy is a human or automated planner and that actual negotiators are simply being 
m unitored by a system in which they can store data or in which data is stored about 
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the r actions, which may have taken place by telephone or fax, and not through direct 
u* of the monitoring system of Kennedy (see Col. 4, lines 12-15: "The request, promise 
arw I acceptance information can also be communicated through other means such as by 
fax phone, etc.".) 

Ap plicants respectfully submit that Kennedy is not a negotiations system at all, but, as 
it s i.ys, a framework for a tracking or monitoring system for a very limited set of 
tra tsaction types related to order and demand management for the sale of goods. 
Ke unedy does not disclose, claim, nor render obvious applicants' invention. 

Af. plicants respectfully submit that all bases for objection and rejection have been 
ov rcome and that Claims 2-98 are in condition for allowance. Reconsideration of all 
th« claims is requested. Allowance of Claims 2-98 at an early date is solicited. 

Ar plicants ' Attorney respectfully requests that if she can be of any further assistance in 
pu ting all the claims in condition for allowance that she be reached by telephone at 
50f -653-8143 or by cellular phone at 508-308-2109 in order to discuss the application 
wi h the Examiner, so that any new objections or rejections may be addressed. 

Da :e: August 20, 2003 



Respectfully Submitted, 




Maureen Stretch 
Reg. No. 29,447 
26 Charles Street 
Natick, MA 01760 



Cu ;t. No. 27,443 
Tel. 508-653-8143 



12 

Received from < 000000000000000000 > at 8/20/03 5:38:29 PM [Eastern Daylight Time] 



